Getting started with Apple Wallet and Passkit

At WWDC 2022 Apple showed some big updates coming to Apple Wallet with the launch of iOS 16. In North America Apple is working hard to roll out more legitimate digital IDs in Apple Wallet like driver licenses and national IDs. Also offering privacy secure features to ensure age-restricted content can only be accessed by people of the right age with their digital ID.

Apple Wallet is also pushing hard on the digital key market, adding the new feature to securely share a key with someone. Sharing digital keys also works with non iOS devices, so for example you can easily share your digital hotel key with all the people you’re on holiday with.

Since 2020 the world is becoming more cashles and the use of Apple Pay is increasing, meaning people don’t want to carry around a traditional wallet with just all their loyalty cards. Every commerce company can also offer their loyalty cards in a digital form through Apple Wallet. This is super convenient for people as everything you needed to carry around in the past, is available on your phone. Also allowing the to user quickly check how many loyalty points they currently have saved up with just a few taps on the phone.

In the next part of this blog article, we will further explore how to implement the service side to power this digital loyalty experience for your company with Apple Wallet.

To work with passes saved in Apple Wallet, an API according to Apple’s specification needs to be deployed on your own server(s). This means that it's your own responsibility to manage this service, which comes with some challenges. The API specification can be read on the official Apple documentation.

There are 2 main API components:

JSON REST API

A simple REST API that needs to be implemented according to Apple’s specification. Mainly used to (un)register devices with passes for push notifications.

Generation of binaries

The actual Apple passes are binaries of the type "application/vnd.apple.pkpas". Generating and streaming binaries tend to be more memory heavy tasks than regular JSON API responses, which needs to be consider in the API/server architecture.

The binary service has different server instance needs than the Passkit JSON API. Eg. The JSON api might run on a fleet of AWS EC2 t3.micro while the binary service runs on a fleet of t3.medium instances. Separating these services also allows more granular scaling of each service, which might be more cost effective.

To be more efficient with compute and also have easier disaster recovery; it’s best practise to save the binaries after generating them. Modern cloud vendors have amazing products for this use case like AWS S3 or Azure Storage. This also allows the generation of binaries to be separated from requesting the binary.

When the user or apple wallet requests the latest version of the pass, the binary will be streamed from the cloud storage service.

When data is updated, this also needs to be reflected on the pass binary. A modern way of solving this challenge is doing it on an event driven manner. An event is put on the event bus when data is updated. The event bus forwards the event to the service which updates the pass binary with the latest data.

Cloud providers offer managed event busses like AWS EventBridge or Azure Event Grid.

To send updates to a pass, the Apple Push Notification Service (APN) is used. When a pass is first opened, the Apple Wallet calls the REST API to register the device push token. Sending an empty push notification with this device push token will trigger the Apple Wallet to retrieve the latest binary from the service.

Since the Passkit API is not managed by Apple themselves, it’s an extra infrastructure and architecture to challenge. All the challenges of a backend service come with it, such as scalability and resiliency. It's a small investment that allows your company to offer amazing user experiences in the digital wallet.